Modern mobile communication systems providing packet switched services, such as Universal Mobile Telecommunication System (UMTS) should be capable of supporting a large and diverse variety of applications having different demands on needed transmission capacity, sensitivity to delays in the transmission and demands on interactivity, for example. The applications range from a simple transfer of a text message, which is an example of an application that does not require high capacity nor is time critical, to video conferencing, which is a real time application requiring high transmission capacity. The concept of Quality of Service (QoS) was introduced to ensure that an end user, running an application, receives the system resources required for that particular application. At the same time, by not using more recourses than necessary for the application, the use of QoS contributes to the optimization of the use of the system resources, in particular the scarce radio resources. How QoS is implemented in UMTS is described in the technical specifications 3GPP TS 23.107 V6.1.0 (2004-03) and 3GPP TS 23.207 V6.2.0 (2004-03).
Illustrated in FIG. 1 is a generic mobile communication system wherein QoS may be utilized. The mobile communication system 100 comprises a client terminal 105 which may communicate with a network node, for example an application server 120, to use service provided by a service provider, for example. The client terminal 105 should be seen as a representation of various equipment, including, but is not limited to, mobile (cellular) phones, laptop computers and PDAs with communication abilities, and is also commonly referred to as User Equipment (UE) or Mobile Station (MS). A radio access network (RAN) 125, a core network (CN) 130 and a service network (SN) 135 are involved and interacting in providing the communication between the client terminal 105 and the application server 120.
In UMTS QoS is defined with a set of attributes that specifies the UMTS bearer service. The UMTS QoS attributes are the following:                Traffic class        Maximum bit-rate        Guaranteed bit-rate        Delivery order        Maximum SDU size        SDU format information        SDU error ratio        Residual bit error ration        Delivery of erroneous SDUs        Transfer delay        Traffic handling priority        Allocation/Retention Priority        Source statistics descriptor        Signalling Indication        
These attributes can be mapped to the pre-defined UMTS QoS classes: Conversational class, Streaming class, Interactive class and Background class. The QoS classes are specified to the communication system by the Packet Data Protocol (PDP) context.
FIG. 2 illustrates schematically communication between a client terminal 105 and the application server 120 in UMTS. The communication occurs via the RNC (Radio Network Controller) 205 and the main nodes SGSN (Serving GPRS support node) 210 and GGSN (Gateway GPRS support node) 215 of the CN 130, to the application server 120 in the SN 135.
In the UMTS implementations the QoS classes are negotiated and managed by using PDP context management. Application level QoS requirements are mapped to PDP context parameters in the client terminal. Pre-configurations of PDP contexts are made in the client terminal such that when a packet switched application starts and connects to the network a matching pre-configured PDP context is activated. This PDP context has a selected QoS class that should match the desired QoS requirements of the application. If for instance the application is a WAP browser or MMS client, the QoS class of the activated PDP context is usually the Interactive class. Illustrated in FIG. 2 with an arrow 220, is the PDP context, defining the required QoS class, originating from the client terminal 115 and received by the GGSN 215.
Today an application, or service node, for example a WWW server may influence the selection of QoS class performed in the client terminal by the Session Description Protocol (SDP). The WWW server may want, in order to effectuate a streaming session, for example, to use a another bearer better suited for the download, than the already in use. The WWW server may then issue a SDP document to the client terminal, specifying the desired QoS class. Subsequently, the client terminal will have to initiate the actual change of QoS, before the downloading can be performed.
As described above the system trusts all terminals to either determine required QoS or to correctly handle the QoS information in the SDP message, and to negotiate with system nodes such as the RNC 205, SGSN 210 and GGSN. However, in a scenario of a larger number of different 3G terminals, from a large plurality of vendors, it is plausible that not all terminals will comply perfectly to the standard. However, it would still be of high importance for a service provider, for example, to be able to ensure that the offered application can be correctly used by the end user. Further, certain changes in the QoS requirements that would be favourable can not be easily foreseen by the terminal.